Is it safe to make this changes to the existing view? Is it worth considering adding a new derived_table so that we don't unintentionally impact existing Looker artifacts?

Looker docs say that it doesn't automatically regenerate derived tables and would use cache (for ex. if no persistent is defined like in this case) which would not show real-time results (which unfortunately has been problematic in the past), To remove the risk, did you consider building a separate view for this derived table or using a PDT?

Is it safe to make this changes to the existing view? Is it worth considering adding a new derived_table so that we don't unintentionally impact existing Looker artifacts?

@bochocki so generally this should recreate what already exists. So nothing should break. The idea behind recreating this resource is that the changes automatically get applied to all existing Looker resources so no additional work is required.

There is an alternative approach that we could consider, this would include adding an additional field in the view, let's call it distribution for now. This would map to corresponding broader distribution, let's say mozilla-001 could be mapped to have value of Mozilla in the new distribution field and then we could set up field suggestions: https://cloud.google.com/looker/docs/reference/param-field-suggestions to make sure the values we want show up in the UI.

@lucia-vargas-a thanks for pointing this out. I was not aware of this Looker thing. I created a PR to pursue an alternative approach here: mozilla/bigquery-etl#6706